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Alexandria, VA 22313-1450 



REPLY BRIEF SUBMITTED UNDER 37 CFR § 41.41 

Dear Sir: 

This is a Reply Brief submitted in response to an Examiner's Answer dated August 6, 
2008 based upon a Final rejection dated February 20, 2008. A response under 37 CFR § 1.116 
was submitted on April 18, 2008. No Advisory Action was ever provided to the present 
Applicants. A Notice of Appeal was submitted by the Applicants on May 20, 2008. An Appeal 
brief was submitted on July 18, 2008. This Reply Brief, due on or before October 6, 2008, is 
thus seen to be timely submitted in response to the abovementioned Examiner's Answer. 
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Preliminarily, it is useful to layout the structure of the present document. Since an 
organized response to the Examiner's Answer is required in order to maximize its effectiveness 
for all readers concerned, the first portion of this Reply Brief is a listing of applicants claim 1 . 
The second portion of this document is directed to that portion of the Examiner's Answer that 
sets forth specific counterarguments to Applicant's assertions. Lastly, the document ends with a 
conclusion of Applicants' position. 

I. Sample Claim 

1 . A method of managing data movement, comprising: 

having common access to data residing in one or more data storage units; 

initiating a data management application (DM) in said environment; 

assigning a node of said cluster as a coordinating node for managing data movement; 

receiving an event by the coordinating node requesting movement of data; 

posting a worker thread to one or more of the nodes to perform data movement in 
response to the event. 

II. Response to Specific Issues 

Issue #1: Sufficiency of the Affidavit 

Issue #1 : Applicants have submitted an affidavit under 37 CFR § 1.131. 

Examiner's Answer #1 : The Examiner has asserted that the affidavit is insufficient. 

Applicant's Reply #1 : The Examiner has failed to consider the fact that Applicants have indeed 
satisfactorily demonstrated the reason for the lack of specific documents. The Examiner fails to 
appreciate that the claimed invention is a software related method. The Examiner is applying 
rule interpretations that might have been appropriate for 19 th century chemical processing where 
the end result is a precipitate at the bottom of a beaker. In the presently claimed method the 
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process results in bits being transferred under well-defined circumstances. The successful testing 
of the method is the discernment that the relevant bits have been transferred. As the Examiner 
should fully appreciate, no one ever actually sees these bit of magnetized regions on the (usually 
rotatable) medium. Yet, does not the Examiner believe that when he hit "ALT-File-Save," the 
bits representing his Answer were transferred to a disk? Did the examiner have to visually see 
these bits in order for him to believe they were there? 

Furthermore, the details of the affidavit established that there are internal procedures used 
for testing code before it is deemed to be usable by a customer. Furthermore, these are rather 
exacting standards. This establishes that there are business records kept in accordance with the 
development and testing of software. The affidavit further establishes that the record with 
respect to the testing of this particular project were kept in accordance with these rules. It 
furthermore establishes that the results of those tests were to flag the code as being ready for 
customer use, should the marketing need arise. Remember that the release of code by the 
assignee of the present invention entails not just its mere release but also its subsequent support 
costs which, without an identified market, are hard to justify. 

The Examiner in his Answer has asserted that the "Applicant is also required to disclose 
where in the disclosures of the documentation the claimed invention is generally disclosed." 
However, neither the statute nor the regulations make any such requirement of an applicant. 
Whether or not such a requirement is indicated in the MPEP is irrelevant. That document is 
intended as a guide the patent examining corps and cannot set forth requirements to be followed 
by applicants since the material in the MPEP has not in any way been vetted by any form of 
public review and comment process as is present and required in the establishment of the body of 
patent regulations. 

Accordingly, it is Applicants' position that the affidavit is indeed sufficient and that there 
is a perfectly logical and justifiable reason why other supporting documentation was not 
otherwise supplied therewith. 
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Issue #2: Anticipation Rejection 



Issue #2 : Whether Claims 1- 20 are anticipated under 35 USC § 102(e) based upon the 
published patent application of Moore et al. 

Applicant's Reply #2 : 

At this point, it seems particularly relevant to discuss those comments of the Examiner 
that appear beginning on page 14 of the Examiner's Answer. This discussion is therefore seen to 
be within the general framework of a Reply Brief which is narrowly directed to those comments 
of the Examiner provided in the Answer. 

It would appear that the Examiner has not fully understood the import of Applicants' 
arguments in several respects. With respect to the first recited claim element, namely, 
"establishing a processing environment in a cluster of nodes. . .," it was Applicants' intent to 
point out that the same claim element is not recited in the patent application of Moore et al. for 
the reasons that the cited application, not simply includes, but requires "two classes of nodes." 
(See page 16 of the Examiner's Answer.) No such limitation is present in the cited claims. For 
this reason, it is seen that applicants first recited claim element is in fact a broader than the 
teachings found in the cited patent application of Moore et al.; being broader, it is in fact 
therefore different. Being different, even though broader, removes it from attack under an 
anticipation ground of rejection. 

On page 1 7 of the Examiner's Answer, the Examiner also makes much of the fact that 
Applicants have argued that the notion of a session node is not to be found within the four 
corners of the cited patent application to Moore et al. but that there is no recitation of a session 
node to be found within the broadest of the rejected claims. In this regard, the Examiner has 
misconstrued Applicants' purpose for pointing out this "difference." Applicants are aware that 
the specific language does not appear in the rejected claims. However, it is noted that there is a 
specific purpose in pointing out the fact that the present Applicants do disclose and also claim 
(in their dependent claims) the use of a "session node" which is used for the processing of 
DM API events. See Applicants' paragraph [0010]: "However, all data migration and recall is 
conducted through a single node called a session node." This is an aspect of DMAPI processing 



POU920030196US1 



-4- 



but it also imposes limitations. In particular, a session node performs a subset of the functions of 
a metadata node which are related to handling DMAPI events as shown in step 138 of Moore et 
al. Session node handling is described in several prior patents (6,990,478; 7,024,582; 7,072,894; 
7,1 1 1,291) assigned to the same assignee as the present invention. However, Moore et al. limit 
DMAPI event processing for a given file system to their metadata node which gives them the 
same problem that led the present inventors to the method described in the present application. 
The I/O requirements of handling DMAPI event processing is limited by the I/O capabilities of 
the session node or metadata node. 

Accordingly, while it is still the case that Applicants' specification is unique in 
specifically mentioning the utilization of a session node, equivalent node functionality is 
apparently described in the application of Moore et al., but it results in the same problem that the 
present application was directed to solving. 

With respect to the Examiner's comments beginning on page 18 of the Examiner's 
Answer, the Examiner has asserted that "the Office again remarks and points out with emphasis 
that '[applicant's references to 'distinct events' and/or a 'single event being processed in a 
parallel fashion' are nowhere to be found in the particular argued limitation of claim 1 .' " 
However, it is noted that the aspect of Applicants' claimed method relating to parallel processing 
is implied in the following language from claim 1 : "posting a worker thread to one or more of 
the nodes to perform data movement in response to the event. It is clear that Applicants' recited 
method fully and completely embraces the notion that more than one node is going to perform 
the desired data movement in response to the event. In this regard, it is to be specifically noted 
that claim language in general is capable of describing certain characteristics of a method which 
are inherent thereto. The fact that a worker thread is posted to one or more nodes to perform data 
movement inherently describes a parallel process. The fact that the word "parallel" docs not 
appear in Applicant's broad claim 1 does not in any way negate the fact that parallel 
processes are inherently described . 

In his answer, the Examiner has asserted that "Moore's teachings and disclosures, as 
cited by the Office, are thus in accordance with the current language of the claim requirements." 
(See page 1 8 thereof.) If the Examiner is in fact correct that Applicants' broad claim 1 is not 
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inherently parallel in nature, then the Examiner's assertion that it is equivalent to the teachings 
found in the cited patent application to Moore et al,, then the Examiner has impliedly admitted 
that the cited application does not indeed teach parallel processing for events of this nature . In 
this regard to sentence at the end of the previous paragraph is highly relevant. 

With respect to the arguments appearing on pages 19-20 of the Examiners Answer, it is 
noted that the Examiner has cited several passages from the application of Moore et al. for the 
sole purpose of asserting that they do in fact disclose a "coordinating node." To whatever extent 
that may be true, they do not disclose a "coordinating node for managing data movement ." 
The only purpose set forth in the passages quoted by the Examiner is for recovery, not for data 
movement . Applicants' broad claim 1 specifically indicates that the purpose of the coordinating 
node is for managing data movement. Recovery is an entirely different function and a node 
whose purpose is related to recovery does not in any way function in the same manner as a 
node whose purpose is related to data movement. They are both nodes but their functions are 
entirely different. Since recited the functionality is different, an anticipation rejection cannot be 
found to be sustained. 

On page 20 of the Examiner's Answer the following paragraph is to be found: 

"Fourth, and in support of his argument that Moore does not teach the recited 
feature of 'receiving an event by the coordinating node...', Applicant remarks and 
notes as a 'reason for difference' that the cited patent application only discloses 
that 'the possible DMAPI events ' are READ, WRITE, and TRUNCATE' and that 
this is not properly discloses the said claim limitation. The Office respectfully 
disagrees." 

Applicant reiterates that there is no event received by anything in the cited patent 
application that can be described as a coordinating node that performs a data movement 
function . Anything that is found in the cited patent application that can be described as a 
coordinating node is dedicated to recovery operations, or to node cluster membership, not to the 
movement of data. Furthermore, anything that could be described as a coordinating node in the 
cited patent application, other than those nodes used for recovery purposes, are seen to be 
directed to handling node membership in various cluster configurations. Again, there is no 
relation to events being processed by a coordinating node relating to data movement. The events 
that are referred to in paragraphs [0075] through [0077] in the cited patent application are not 
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processed by coordinating nodes. Any references therein to a "leader node" is in fact directed to 
a node that only performs recovery and cluster membership operations. The reference in these 
paragraphs to a leader node is not in any way whatsoever a reference to a node to which a 
13 M A PI event is directed . Furthermore, there is nothing in the language found within the cited 
paragraphs that teach, disclose, or remotely suggest any form of parallel processing. 

In particular, it is noted that the Examiner cites the following language from the cited 
patent application: "The DMAPI event is queued 136 and subsequently processed 138 by 
DMAPI 90 and HSM 88." There is absolutely nothing here which suggests that anything other 
than normal DMAPI processing occurs. In this regard, it should be fully appreciated by the 
Examiner that, in many respects, the present invention is directed to an improvement in the 
simple processing set forth in step 138 of the cited patent application. This improvement is 
particularly set forth in the last recited step of Applicants' claim 1 . 

Most Significant Difference 

Primarily for the purpose of focusing attention on what is currently perceived as being 
the most relevant one of the Applicants' arguments, this section has been labeled as "most 
significant difference." Because of its relevance and significance, the language which is being 
compared is set off between lines of boldface asterisks below. Attention is now directed to the 
following language found in the cited patent application to Moore et al., and heavily relied upon 
by the Examiner: 

*** 

[0103]: "An RPC is a thread initiated on a node in response to a message from 
another node to act as a proxy for the requesting node." 

The Examiner reads this language as being equivalent to the following language found in 
applicants claim 1 : 

".. . posting a worker thread to one or more of the nodes to perform data 
movement in response to the event." 
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The cited language is nothing other than a definition of a Remote Procedure Call (RPC), 

nothing more nothing less . The language cited above should also be taken in context with other 
language found in Applicants' claim 1, notably: "receiving an event by the coordinating node 
requesting movement of data." The cited language from Moore et al. does NOT indicate that a 
thread is being posted. The language does NOT refer to a response to an event by a coordinating 
node (the event). The language does NOT refer to a request for data movement. (Here the 
Examiner utterly gratuitously throws in parenthetical references to "leader nodes" and other 
items without any justification whatsoever.) 

It is furthermore noted that the cited definition of an RPC occurs in a context 
utterly unrelated to requests for data movement. It is merely a definition of something 
which happens to be a thread. Other than that, it is totally and utterly irrelev ant. It is 
merely a definition of a particular kind of thread. It does not teach, disclose, or suggest the 
posting of threads nor does it teach, disclose, or suggest the posting of a particular kind of 
thread. It does not teach, disclose, or suggest the context or circumstances under which 
any particular thread is to be posted or used. Furthermore, the particular thread referred 
to has nothing whatsoever to do with data movement. 

The cited claim element is therefore seen not to be taught by or within the grasp of the 
teachings found within the patent application of Moore et al. Accordingly, for this reason as well 
is seen that there are claim elements which are not found within the four corners of the cited 
patent application. It is therefore seen that and anticipation rejection cannot be sustained based 
upon the particular art cited. Accordingly, it is therefore very respectfully requests that the 
anticipation rejection of Applicants claims 1-20 be withdrawn and that the claims be passed on 
to early an allowance, link 

Issue #3: Obviousness Rejection 

Issue #3 : Whether Claims 5-8 are rendered obvious under 35 USC § 103 based upon the 
aforementioned Moore et al. application in further review of the published patent application 
of Dugan et al. 
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Applicant's Reply #3 : 



Put simply, it is Applicants' position that the base patent upon which the Examiner relies 
fails to teach, disclose, or suggest significant aspects of the invention as set forth in claim 1 . 
These differences have been amply described in the paragraphs above dealing with issue #2 
above. 

For purposes of considering the obviousness rejection, it is best to consider Applicants' 
claims 5 and 6 together. They are repeated below for the convenience of all. 

5. The method of claim 1, further comprising establishing a process session in 
said cluster and assigning a session identifier for that session. 

6. The method of claim 5, further comprising providing said session identifier to 
said one or more nodes to which said worker threads are posted, and permitting 
only the one or more nodes having said session identifier to execute said 
worker thread . 

It is not enough that an Examiner is simply permitted to locate a word, such as "session," in this 
or that document and assert that it is: (1) the same concept; and (2) used in the same sense and 
connected to the other items in the claims in the same fashion. Moore et al. use the term 
"session" only because the DMAPI standard requires it. Furthermore, Dugan et al. use it 
differently. It should also be fully appreciated by the Examiner that the term "session" appears 
only once in the base patent upon which the Examiner relies. Furthermore, that use of the term 
"session" has nothing whatsoever to do with the DMAPI standard. Additionally, apart from the 
fact that it is used in the standard, the term "session" has no use in the cited patent application of 
Moore et al. The added patentable value set forth in claim 5 is that the session identifier has 
meaning on multiple threads running on multiple nodes. Nothing in Moore et al. goes in that 
direction and Dugan has a different concept of session. 

As previously stated, the only recitations found in the cited patent to Moore et al. is found 
in reference to a "telnet" session. This has actually nothing whatsoever to do with a DMAPI 
session. While the standard may refer to a session node, there is nothing contained within the art 
cited which makes any reference whatsoever to "a session identifier." The notion of a session 
identifier only makes sense in the context set forth in Applicants' claim 6, as set forth above. It 
is seen that the session identifier has utilization in "permitting only the one or more nodes having 
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said session identifier to execute said worker thread." There is nothing contained within the 
cited the patent applications relied upon by the examiner that would lead one of ordinary skill in 
the art to employ a process in which the step shown in block 1 38 is carried out by a plurality of 
worker threads running on multiple nodes at the same time. There is but one single reference in 
the patent application of Moore et al. which references block 138. That reference simply states: 
"The DMAPI event is queued 136 and subsequently processed 138 by DMAPI 90 and HSM 88." 
This is the beginning and ending of any and all teachings with respect to the processing of 
an indicated DMAPI event! 

With respect to the concept of a "session," the following is a summary of 
Applicants' position. The DMAPI standard refers to the concept of a session. There is, 
however, no concept therein relating to having multiple nodes carrying out data movement 
operations in parallel where in these nodes are linked by a common session identifier. The 
patent application of Moore et al. refers to the DMAPI standard but does not in any sense 
whatsoever refer to a session as that term is defined in the standard. Furthermore, the 
application of Dugan et al. carries with it an entirely different notion of what a session is. 

It is furthermore noted that the recitation in Applicants' claim 6 of "permitting only the 
one or more nodes having said session identifier to execute said worker thread" is further 
evidence of the implied parallel structure imparted to the claimed invention. 

Accordingly, it is seen that Applicants' claims 5-8 are not in any way rendered obvious 
under 35 USC § 103 based upon the aforementioned Moore et al. application in further review of 
the published patent application of Dugan et al. It is therefore very respectfully requested that 
this rejection be reversed as well. 

IV. Conclusion 

It is therefore seen that the subject claims are clearly patentable over the art cited. For all 
the reasons stated above, it is seen that the rejections of Applicants' claims 1-20, as set forth 
above cannot be sustained. It is therefore very respectfully requested that the rejection of 
Applicants' claims be reversed. 
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RESPECTFULLY SUBMITTED 



Dated: October 6, 2008 



Lawrence D. Cutter 
Registration No. 28,501 
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5 Columbia Circle 

Albany, New York 12203-5160 

Office Phone: (518) 452-5600 

FAX: (518) 452-5579 

Direct Phone: (845) 255-3276 
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